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ABSTRACT 


The  problem  addressed  by  this  research  is  that  there  does  not  exist  a  command  and 
control  system  for  the  next  generation  U.S.  Naval  amphibious  class  of  ship,  LPD-17.  A 
system  is  needed  that  coherently  displays  information  required  by  commanders  to  make 
timely  and  correct  decisions.  This  research  examines  this  problem  in  the  context  of 
designing  a  user-interface  display  that  will  access  data  on  the  ship’s  underlying  network  to 
exercise  command  and  control. 

The  approach  taken  to  solve  the  problem  has  four  parts.  First,  system  requirements 
were  captured  by  interviewing  23  senior  officers  with  command-at-sea  experience  to 
isolate  design  features  they  require  from  such  a  command  and  control  system.  Second,  a 
mock-up  display  was  designed  based  on  these  requirements;  the  mock-up  was  then 
iteratively  tested  in  the  fleet  with  subject  matter  experts  to  ensure  it  captured  the  required 
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elements  of  command  and  control.  Third,  a  user-interface  display  was  then  constructed 
using  a  personal  computer  and  Asymetrix  application  Multimedia  Toolbool™;  that  is,  a 
prototype  was  made  without  connecting  to  the  underlying  data.  Fourth,  this  prototype  was 
then  iteratively  reviewed  during  design  by  fleet  operators  to  validate  that  the  command 
and  control  process  could  be  executed  from  this  workstation.  The  result  of  this  research  is 
a  set  of  18  example  displays  that  will  be  forwarded  to  NAVSEA  and  the  contractor  for 
consideration  during  actual  system  design. 
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I.  INTRODUCTION 


This  thesis  addresses  the  design  of  a  prototype  human-computer  interface  for  a 
command  and  control  system  which  will  be  in  place  on  the  next  generation 
amphibious  platform:  LPD-17.  The  Naval  Sea  Systems  Command  (NAVSEA)  is 
charged  with  developing  this  interface,  and  has  already  produced  a  preliminary  fiber¬ 
optic  based  network,  the  Integrated  Interior  Communication  and  Control  (IC)2  System, 
which  will  provide  the  required  data  for  command  and  control.  This  research 
incorporates  data  gathered  during  interviews  of  Commanding  Officers  of  surface 
combatants;  it  evaluates  and  distills  design  features  they  would  desire  from  such  a 
command  and  control  system.  A  set  of  engineering  design  recommendations  is 
proposed  for  the  system’s  informational  interface. 

The  thesis  has  four  parts.  The  introduction  provides  an  interpretation  of  the 
general  problem  and  NAVSEA’s  current  solution  to  it.  The  second  part  reviews  the 
methods  used  to  extract,  isolate,  and  integrate  command  and  control  design 
recommendations.  The  third  part  reviews  the  analytic  interpretation  of  users’  desires; 
how  these  desires  were  translated  into  system  characteristics,  and  how  these 
characteristics  were  incorporated  into  prototype  displays.  The  final  part,  the 
discussion,  critically  evaluates  the  present  method’s  findings  and  products,  and 
recommends  future  courses  of  action. 

A.  NATURE  OF  THE  PROBLEM 

This  section  discusses  problems  associated  with  current  command  and  control 
systems.  It  identifies  the  problems  experienced  on  surface  combatants  and  discusses 
why  it  is  important  to  accommodate  these  problems  during  the  design  of  new  systems. 
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Two  broad  shortfalls  account  for  usability  *  problems  with  command  and 
control  systems  used  in  the  surface  Navy  today: 

s  There  is  a  lack  of  understanding  about  how  the  user  reads,  interprets,  and  uses 
information,  and 

9  There  are  few  user  inputs  during  the  design  process. 

By  extension,  these  deficiencies  are  at  the  root  of  two  common  human-computer 
interface  weaknesses: 

9  User-defined  information  requirements  are  not  readily  available;  as  a  result, 
interface  displays  do  not  adequately  depict  what  the  user  wants  to  see. 

9  Information  displayed  in  lieu  of  that  which  the  user  wants  is  often  difficult  to 
comprehend  in  a  timely  and  efficient  manner. 

A  third  related  problem  deals  with  the  complexities  involved  with  designing  a 
system  to  support  command  and  control  on  U.S.  Navy  ships.  The  warfare  environment 
in  which  these  ships  operate  is  continually  changing,  ultimately  compressing  the 
battlespace  time-line.  This  change  in  warfare,  in  the  face  of  advancing  technology, 
threatens  to  overwhelm  the  decision-maker  during  the  process  of  command  and 
control.  Potentially  too  much  information  is  made  available  and  the  user  is  forced  to 
deal  with  the  serious  problems  associated  with  inductive  ^  logical  processes.  The  users 
are  forced  to  select  small  bits  of  information  from  the  vast  amounts  of  data  available  to 
comprehend  the  situation  and  reach  a  decision.  When  existing  deficiencies  are 
combined  with  the  changing  complexities  of  surface  warfare,  proper  design  of  the 
user  interface  becomes  one  of  the  most  important  aspects  to  consider  during  the  design 
and  development  of  the  system  itself. 


1  Usability  is  related  to  the  effectiveness  and  efficiency  of  an  interface,  and  to  the 
user’s  reaction  to  that  interface  (Hix,  1993). 

^  Inductive  reasoning  involves  drawing  conclusions  from  specific  events.  The  lexical 
definition  of  ‘‘inductive”  is  “...inference  of  a  generalized  conclusion  from  particular 
instances....”  (Websters,  1990,  pp.  615)  The  opposite  of  inductive  reasoning  is 
deductive  reasoning  — a  conclusion  reached  from  observing  generalities. 
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Tactical  displays  have  not  improved  dramatically  until  the  last  few  decades. 
From  the  days  of  Nelson’s  Trafalgar  in  1805  when  messages  were  sent  by  flag  signal, 
to  the  fleets  of  World  War  Two  when  radar  and  plexiglass  grease  boards  were  first 
used,  much  of  the  information  that  was  passed  along  was  hearsay.  The  data  used  for 
command  and  control  was  what  someone  else  said,  or  saw.  In  the  recent  past,  and  with 
the  advancement  of  electronic  devices,  displays  now  can  accurately  depict  real-time 
data;  but  while  the  typical  decision  process  has  not  changed,  the  workload  on  the  user 
has  continued  to  increase.  “Modem  computer  power  has  opened  the  possibility  of 
augmenting,  assisting,  and  supplementing  the  decision  process  of  commanders  by 
synthesizing  for  display  the  information  on  decision  alternatives.”  (Snyder,  1993,  pp. 
63)  Effective  design  of  command  and  control  interfaces  must  ensure  that  computers 
assist  in  reducing  the  workload  and  help  solve  problems  associated  with  decision 
making. 

The  heart  of  the  problem  is  straight-forward.  Decision  aiding  interfaces  used 
today  often  provide  the  user  with  too  much  data  and  not  enough  information.  As 
technology  advances  and  the  volume  of  information  available  to  the  decision  maker 
expands,  the  user  needs  help  to  discern  the  available  options  from  a  tactical 
perspective.  As  present  and  future  tactical  encounters  become  increasingly  complex, 
decisions  and  actions  are,  and  will  continue  to  be,  time  constrained;  multiple  decisions 
and  required  actions  must  be  made  in  a  matter  of  seconds.  Decisions  must  be  made  in 
milliseconds  and  use  all  relevant  information  at  the  time.  The  relevant  information 
must  be  isolated,  redundancies  and  ambiguities  must  be  eliminated,  and  the  system 
must  provide  information  when  and  how  the  operator  or  decision  maker  needs  it. 

Data  and  information  are  different,  and  this  difference  must  be  clarified.  In  the 
past,  these  two  terms  were  used  interchangeably,  but  today’s  saturated  information 
environment  highlights  a  significant  difference  in  their  meaning.  The  International 
Standards  Organization  (ISO)  defines  data  as  “...a  representation  of  facts,  concepts,  or 
instructions  in  a  formalized  manner  suitable  for  communication,  interpretation,  or 
processing  by  human  beings  or  by  automatic  means.”  (American,  1972,  pp.  33) 
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Information  is  defined  as  “...the  meaning  that  is  currently  assigned  to  data ...” 
(American,  1972,  pp.  63)  An  effective  user-interface  is  one  that  displays  data  so  that 
information  is  effectively  and  effortlessly  imparted  to  the  user. 

To  fully  understand  command  and  control  and  how  it  relates  to  the  surface 
Navy,  this  section  will  review  the  following  four  areas: 

°  The  Basks  of  Command  and  Control.  The  traditional  elements  of 
command  and  control  are  discussed.  Command  and  control  is  defined,  and  a 
model  of  how  decisions  are  made  is  presented. 

°  Increasing  Complexities  of  Command  and  Control.  The  reasons  for  the 
increase  in  information  flow  and  the  changing  complexities  in  command  and 
control  systems  are  explored. 

9  Case  Studies;  A  review  of  user-interfaces.  Two  studies  are  conducted  and 
user-interfaces  are  compared.  The  first  study  reviews  the  incident  of  USS 
VINCENNES  and  the  shoot  down  of  a  commercial  airliner.  This  is  an 
example  of  how  the  Navy’s  most  advanced  command  and  control — and 
weapon  system — did  not  lead  its  users  to  the  proper  decisions.  The  second 
study  reviews  the  Integrated  Condition  Assessment  System  (ICAS),  a 
computer  based  analysis  and  diagnostic  tool  used  to  monitor  onboard 
equipment.  This  system  has  extensively  involved  the  intended  operator  in  the 
initial  design  of  the  interface. 

*  Human  Performance  in  Command  and  Control.  How  human  capabilities 
and  limitations  come  into  play  during  decision  making  is  reviewed. 


The  following  reviews  command  and  control  to  provide  the  reader  with  a  very 
basic  background  in  command  and  control — what  command  and  control  is,  and  what 
elements  are  involved  with  it.  Contemporary  command  and  control  components  are 
first  reviewed  to  familiarize  the  reader  with  what  is  commonly  available  in  the  fleet. 
Command  and  control  is  then  defined,  followed  by  a  model  which  displays  the  basic 
steps  associated  with  command  and  control. 
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a.  Contemporary  Command  and  Control  Systems  of  the  Surface 
Navy 

In  the  surface  Navy,  command  and  control  systems  that  are 
predominantly  in  use  are  products  that  were  designed  and  built  during  the  period  from 
the  1960’s  to  the  1980’s — a  20  year  period  during  which  the  application  of  computer 
technology  began.  Today,  however,  many  of  these  systems  are  obsolete,  in  part,  due  to 
rapidly  advancing  technology  and  the  long  development  cycle  these  systems  required, 
and  in  part,  due  to  the  slow  military  procurement  process.  To  understand  the  problems 
that  exist  with  current  command  and  control  systems,  it  is  important  to  know  the  basic 
components  that  are  available  to  assist  with  decision  making.  Typical  command  and 
control  systems  used  by  today’s  surface  Navy  involve  a  combination  of  both  computer 
based  and  non-computer  based  components  to  help  the  decision-maker.  The  following 
components  comprise  a  typical  media  mix: 

•  computer  monitors  or  large  display  screens, 

•  automatic  status  boards, 

•  grease  boards, 

•  hand  written  pass-down  logs,  and 

•  internal  and  external  communications. 

Using  such  a  media  mix,  the  user  is  required  to  shift  his  attention  between  the  display 
devices  to  retrieve  essential  pieces  of  information.  For  a  number  of  reasons,  these 
systems — systems  which  should  support  decision  making  during  the  process  of 
command  and  control — can  be  designed  to  better  support  the  usee 
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k  Command  and  Control  Defined 

The  Joint  Chiefs  of  Staff  define  “command”  as 

The  authority  which  a  commander  of  the  military  service  lawfully 
exercises  over  subordinates  by  virtue  of  rank  or  assignment. 
Command  includes  the  authority  and  responsibility  for  planning  the 
employment  of,  organizing,  directing,  coordinating,  and  controlling 
military  forces  for  the  accomplishment  of  assigned  missions.  It  also 
includes  responsibility  for  health,  welfare,  morale  and  discipline  of 
assigned  personnel.  (Joint  Chiefs  of  Staff,  1972,  pp.77) 

This  definition  implies  specific  action  taken  by  the  commander — organizing  forces  for 
optimal  performance,  directing  force  actions  to  accomplish  a  mission,  or  acting  to 
achieve  established  goals. 

The  commander  exercises  command  through  a  process  called  command 
and  control.  Command  and  control  is: 

The  exercise  of  authority  and  direction  by  a  properly  designated 
commander  over  assigned  forces  in  the  accomplishment  of  the  mission. 
Command  and  control  functions  are  performed  through  an 
arrangement  of  personnel,  equipment,  communications,  facilities  and 
procedures  which  are  employed  by  a  commander  in  planning,  directing, 
coordinating,  and  controlling  forces  and  operations  in  the 
accomplishment  of  the  mission.  (Joint  Chiefs  of  Staff,  1972,  pp.77) 

“...commanders  must  be  given  certain  specific  capabilities  that  include  the  ability  to 
communicate  to  higher  and  lower  command  levels,  obtain,  process,  analyze, 
synthesize,  and  display  information.”  (Adriole,  1990,  pp.  67) 

c.  A  Model  of  the  Command  and  Control  Process 
Command  is  the  charge  of  the  commander.  Command  and  control  is 
the  process  the  commander  uses  to  exercise  command.  Command  and  control  reflects 
decisions  which  enable  the  commander  to  impose  or  express  his  will  to,  or  on, 
subordinates.  A  highly  simplified  approach  which  diagrammatically  represents  the 
command  and  control  process  is  depicted  in  Figure  1,  on  page  7. 

To  evaluate  the  situation  and  determine  the  appropriate  response,  the 
commander  must  fully  comprehend  his  continually  changing  environment.  The 
commander  must  assess  the  situation  to  determine  how  to  act.  In  assessing  the 
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situation,  he  must  observe  the  information  displayed  by  the  supporting  system,  process 
what  he  is  looking  at,  and  compare  what  (he  thinks)  exists  with  what  must  be  done  to 
reach  the  desired  goal.  The  commander  must  then  decide  the  best  course  of  action, 
and  act.  Simply  stated,  the  commander  must  determine: 

•  What  is  happening?  And, 

•  What  can  I,  or  should  I,  do  about  it? 

Systems  that  are  to  support  command  and  control  must  help  the  user  with  the  first  step 
of  the  decision  process:  they  must  help  the  user  assess  the  situation.  Specifically,  a 
command  and  control  system  must  assist  in  observing,  processing  and  comparing 
information — not  data — so  the  operator  can  make  better,  faster  decisions.  It  is  task  that 
is  becoming  more  difficult  as  technology  advances  and  surface  warfare  changes. 


1. 


2. 


Decide 


What  is  best  course  of  action? 


Act 


Figure  1:  Model  of  the  Basic  Steps  Followed  during  Command  and  Control 
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2„  Increasing  Complexity  of  Command  and  Control 
The  compression  of  traditional  battlespace  in  littoral  ^  warfare,  coupled  with 
the  proliferation  of  modem  anti-ship  weapons  has  created  a  serious  challenge  for 
today’s  naval  tactician.  The  human  ability  to  recognize,  evaluate,  and  react  to  the 
rapid  flow  of  various  types  of  information — tactical,  own  ship  and  administrative — 
with  non-integrated  shipboard  systems  has  simply  become  physically  and  mentally 
overwhelming.  If  decision  aids  are  to  effectively  guide  the  user  to  make  correct 
decisions  systems  designed  to  assist  decision-makers  must  be  designed  differently 
than  they  have  been  in  the  past. 

The  changing  role  of  the  U.S.  Navy  continues  to  drive  the  development  and 
production  of  new  command  and  control  systems.  As  stated  in  the  Navy  and  Marine 
Corps  White  Paper  ...From  the  Sea,  “The  future  vision  of  the  Navy  will  focus  on 
strategic  deterrence  and  defense,  forward  presence,  crisis  response,  and 
reconstitution.”  (U.  S.  Navy,  September  1992,  pp.  1)  The  demise  of  the  Soviet  Union 
and  the  rapid  worldwide  expansion  of  advanced  technology  to  Third  World  countries 
have  resulted  in  a  rapid  shift  away  from  emphasis  on  open-ocean  global  warfare  to 
regional  or  limited  conflicts  involving  Third  Word  nations  in  littoral  waters. 
a.  Impact  of  Littoral  Warfare 

The  littoral  environment  is  characterized  by  dense  commercial  air 
traffic  and  merchant  shipping  which  presents  challenges  to  command  and  control 
systems  and  their  operators.  This  environment  and  the  projected  threat  will  challenge 
the  detection  range,  reaction  time,  defensive  performance,  and  display  mechanisms  of 
the  system  used  against  the  threats.  The  battlespace  in  which  shipboard  systems  are  to 
react  in  will  be  limited  (Ousbome,  1993).  “Facing  the  future,  we  must  prepare  to  deal 
with  a  foe  at  ranges  so  close  that  the  incoming  weapons  are  at  best  only  a  few  seconds 
away.”  (Owens,  1993,  pp.  90) 


^  Littoral  warfare  is  the  placement  of  traditionally  open-ocean  warships  in  a  coastal 
environment  in  support  of  troops  on  land. 
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b .  Impact  of  Increased  Complexity  in  Information  Systems 
In  addition  to  the  rapidly  changing  warfare  environment  in  which  the 
Navy  operates,  each  successive  generation  of  warship  has  become  technologically 
more  complex.  Present-day  command  and  control  systems,  and  procedures,  must 
accommodate  the  explosion  of  data  and  the  associated  complexities  of  information 
distribution.  In  the  near  future,  all  voice,  video,  and  data  will  be  transmitted  across  a 
common  medium — fiber  optics.  The  subsequent  integration  of  this  data  using 
common  computers  and  databases  will  allow  for  the  real-time  display  of  any 
information  that  is  conceivable.  The  challenge  no  longer  exists  in  detecting  and 
recognizing  data  but  in  selecting  the  essential  information  from  this  huge  amount  of 
data  required  to  make  a  time  critical  decision. 

The  more  technology  advances,  the  more  complex  command  and 
control  becomes.  To  ensure  operators  make  the  best  and  fastest  decisions  possible,  the 
following  must  be  accomplished: 

•  Improve  integration  and  increase  the  automation  of  sensors,  weapons,  and 
display  systems  to  shorten  reaction  time  and  coordinating  responses. 

•  Enable  the  Commanding  Officer,  and  subordinate  watchstanders,  to  direct 
and  monitor  the  overall  operation  of  on  board  systems  in  this  environment. 
(Ousbome,  1993) 

•  Provide  seamless  command,  control  and  communications  to  effectively 
operate  in  this  complex  sea-air-land  battle. 

Accomplishing  these  tasks  will  lessen  the  complexities,  and  relieve  much  of  the 
burden  associated  with  decision  making. 

3.  Case  Studies:  A  Review  of  Two  User-Interfaces 

As  the  command  and  control  process  continues  to  become  more  complex,  so 
does  the  process  of  designing  command  and  control  systems.  The  display  element  of 
decision  aiding  equipment — the  human-computer  interface  that  the  decision  maker 
will  use  to  access  data — is  becoming  one  of  the  most  crucial  elements  of  design. 
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The  tactician  of  tomorrow  is  waiting  for  the  designer  of  today  to 
create  a  system  that  will  help  him  understand  his  environment  so  that 
he  can  fight  a  better  fight  and  live  another  day.  (Willey,  1988,  pp.  292) 

Research  into  the  elements  of  command  and  control  is  not  a  new  field,  yet  the 
manner  in  which  information  is  displayed  has  not  adequately  focused  on  the  end-user. 
Computer  system  interfaces  must  be  designed  with  the  user  in  mind.  System  designers 
must  consider  the  human  element.  Data  must  be  conditioned  and  displayed  so  that  it 
becomes  an  effective  tool  for  decision  makers. 

In  today’s  high-tech  environment,  systems  can  provide  more  data  than  the 
human  can  process.  The  mental  act  of  processing  streams  of  rapidly  changing  data 
from  multiple  sources  often  induces  information  overload,  a  situation  where  more 
information  is  provided  than  an  operator  can  handle.  The  same  information  at 
sufficient  volumes  with  insufficient  time  in  which  to  process  it  can  also  cause  a 
breakdown  in  communication  between  operators.  As  previously  discussed,  both 
advancing  technology  and  the  compression  of  the  traditional  battlespace  have  made 
the  flow  of  information  virtually  unrestricted.  Interfaces  designed  to  support 
command  and  control  of  surface  combatants  must  accommodate  and  compensate  for 
the  possibility  of  operator  information  overload.  The  continually  complex  and  ever 
changing  environment  of  the  surface  Navy  demands  that  computer  systems  must  be 
designed  around  the  conditions  in  which  they  will  be  used.  Command  and  control 
systems  must  reflect  how  human  performance  is  affected  by  the  characteristics  of  that 
work  environment. 

Two  case  studies  follow.  The  first  is  a  review  of  the  shoot  down  of  Iran  Air 
flight  655 — an  A-300  Airbus — in  the  Persian  Gulf  in  July  1988  by  USS  VINCENNES 
(CG  49)  4 .  This  event  clearly  shows  that  the  AEGIS  weapon  system  interface — in  all 
essence  the  shipboard  command  and  control  system — could  have  been  better  designed 

4  USS  VINCENNES  is  a  Ticonderoga  Class  Cruiser.  This  ship  uses  the  AEGIS 
Weapon  System,  the  most  advanced  computerized  shipboard  weapon  system  based 
around  a  3-dimensional  radar.  Anti-air  warfare  is  the  primary  mission  of  this  class  of 
ship. 
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to  accommodate  the  strengths  and  limitations  of  its  operators.  The  system  was  not 
“user  friendly:”  the  results  were  tragic.  The  second  study  reviews  the  Integrated 
Condition  Assessment  System  (ICAS),  a  real-time  computer-based  analysis  and 
diagnostic  tool  used  to  monitor  on  board  engineering  equipment.  This  system 
successfully  focused  on  the  needs  of  the  intended  user  by  keeping  the  subject  matter 
experts  involved  throughout  the  design  process. 

a.  USS  VINCENNES:  Was  it  Only  Operator  Error? 

The  accurate  display  of  timely  information  on  U.S.  Navy  ships  greatly 
affects  command  decisions.  This  case  exemplifies  how  the  technologically  advanced 
AEGIS  Weapon  System  may  not  have  effectively  guided  its  users  in  making  correct 
decisions.  A  summary  of  the  incident  is  provided  in  Appendix  A,  on  page  55. 

(1)  Design  Weaknesses  in  VINCENNES’  System.  The  written 
reports,  published  after  the  incident — including  the  official  investigation  conducted  by 
Rear  Admiral  Fogarty — and  testimony  from  a  House  Armed  Services  Committee 
review  concluded: 

•  the  downing  was  “not  the  result  of  negligent  or  culpable  conduct...”  (Fogarty, 
1988,  pp.  43) 

•  the  Commanding  Officer  “...[acted]  properly  and  responsibly  in  responding  to 
an  unknown  threat,  holding  his  fire  until  the  last  possible  minute.”  (Hill, 
1988,  pp.  108)  and 

•  the  AEGIS  weapon  system  performed  excellently — as  it  was  designed  (Hill, 
1988). 

The  Fogarty  report  did  not  find  any  malfunctions  by  the  AEGIS 
weapon  system;  however,  it  did  recognize  that  specific  pieces  of  equipment  were 
misused  by  individual  operators,  resulting  in  erroneous  reports  of  the  aircrafts’ 
descending  altitude  and  IFF.  Testimony  from  human  factor  specialists  however,  did 
find  fault  with  the  design  of  the  AEGIS  weapon  system,  “...human  error  probably 
contributed  to  the  accident,  but  not  in  the  way  the  Fogarty  report  contends,  ‘It  was 
human  error’,  he  says,  ‘on  the  part  of  the  people  who  designed  the  system.’”  (Hill, 
1989,  pp.  113) 
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The  Fogarty  report  did  not  find  fault  with  the  system;  however, 
it  is  apparent  from  the  result  of  this  incident,  the  loss  of  290  lives,  that  the  AEGIS 
system — the  “cutting-edge”  of  technology  employed  by  the  U.S.  Navy — was  not 
thoroughly  designed  with  the  user  in  mind.  The  report  did  not  say  that  the  AEGIS 
weapon  system  was  not  “user  friendly”  but  the  following  events  did  occur: 

°  operators  misidentified  the  airliner, 

•  operators  incorrectly  determined  that  the  airliner  was  decreasing  in  altitude, 

•  operators  misread  the  aircrafts  IFF  5 , 

•  operators  incorrectly  determined  that  the  airliner  was  outside  of  the 
commercial  air  corridor, 

•  one  operator  incorrectly  pushed  an  action  button  23  times  trying  to  get  the 
system  to  perform  (Hill,  1988,  pp.  204)  and, 

9  those  in  the  chain  of  command  on  VINCENNES,  including  the  Commanding 
Officer,  did  not  use  information  presented  to  them  at  their  consoles, 
information  which  would  have  accurately  indicated  that  the  aircraft  was 
indeed  neither  descending  in  altitude,  nor  preparing  to  take  an  attacking 
posture. 

The  report  did  not  state  that  the  AEGIS  weapon  system  failed  to 
display  information  in  a  manner  that  was  intuitive  to  the  user.  That  omission,  however, 
is  one  of  the  conclusions  which  can  easily  be  drawn.  Had  design  issues,  like  the 
intuitive  display  of  information,  and  human  factors  issues,  like  mental  processing 
capabilities  and  limitations,  been  adequately  addressed  earlier,  the  operators  may 
never  have  been  in  a  situation  where  so  many  disjoint  errors  would  have  resulted  in  a 
mistake  of  this  magnitude. 

b.  Integrated  Condition  and  Assessment  System  (ICAS) 

The  Integrated  Condition  and  Assessment  System  (ICAS)  will  provide 
future  generations  with  the  ability  to  retrieve  all  required  data  about  a  shipboard 


^  Identification  Friend  or  Foe  (IFF)  is  an  electronic  challenge  and  reply  system  that 
uniquely  identifies  aircraft.  This  system  is  required  on  all  aircraft. 
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engineering  plant  from  a  personal  computer  monitor.  This  system  is  currently  being 
designed  by  the  NAVSEA,  Controls  and  Monitoring  Systems  Group,  and  although  it  is 
not  labeled  as  such,  designers  are  using  a  user-centered  approach  to  design  the  ICAS 
interface.  Intended-users  with  significant  fleet  experience  have  provided  the  basic 
requirements  around  which  the  system,  and  intuitive  interface,  are  being  designed. 
These  intended-users  are  the  driving  force  in  determining  the  system  characteristics. 

This  type  of  design  approach  will  allow  designers  to  initially  build  and 
later  modify  the  display  in  accordance  with  the  desires  of  the  users.  It  is  essential  to 
ensure  that  these  user-defined  requirements  are  tailored  from  the  beginning  with 
consideration  into  how  the  intended-user  will  “see”  and  “process”  these  displays. 
Human  factors  must  be  considered  during  design. 

4.  Human  Factors  in  Command  and  Control 

Human  factors  is  the  study  of  human  behavior  based  on  empirical  ^  testing. 
The  goal  of  human  factors  in  interface  design  is  to  make  systems  usable.  Usability  is 
the  optimization  of  human  performance  by: 

•  maximizing  information  transfer, 

•  reducing  errors, 

•  increasing  throughput, 

•  maximizing  user  satisfaction. 

Design  of  command  and  control  systems  must  ensure  that  the  display  is 
intuitive  and  natural  for  the  end-user.  The  user  should  not  have  to  adapt  to  the 
interface.  When  designing  command  and  control  systems,  human  factors  must  be 
realized  and  accommodated.  The  display  of  information  elements  is  critical  to  the 
success  of  a  command  and  control  system.  Design  must  focus  on  the  desires  and 
limitations  of  the  end  user.  The  former  Commander  of  the  Joint  Chiefs  of  Staff, 
Admiral  WJ.  Crowe,  recognized  that  improvements  were  required  in  the  command 

^  Empirical  is  defined  as  relying  on  experience  or  observation  alone. 
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and  control  displays  of  the  AEGIS  weapon  systems.  This  recommendation  came  after 
the  VINCENNES  incident: 

...  I  recommend  that  some  additional  human  engineering  be  done  on 
the  display  systems  of  AEGIS.  The  objective  would  be  to  better  equip 
it  for  assisting  with  rapid  decisions  in  a  situation  such  as  VINCENNES 
confronted....  It  seemed  to  our  inexperienced  eyes  that  the 
Commanding  Officer  should  have  some  way  of  separating  crucial 
information  from  other  data.  Moreover,  the  vital  data  should  be 
displayed  in  some  fashion  on  the  LSD  ^  so  the  Commanding  Officer  and 
his  main  assistants  will  not  have  to  shift  their  attention  back  and  forth 
between  displays.  (Crowe,  1988,  pp.  8) 

a.  Human  Performance:  Capability  and  Limitations 

Human  performance  must  be  recognized  and  considered,  it  must  have  a 
direct  impact  on  the  design  of  a  decision-aiding  system.  As  exemplified  at  the 
VINCENNES  hearings 

...the  ship’s  sophisticated  AEGIS  radar  and  computerized  battle 
management  system  worked  properly,  but  that  some  of  the  men 
monitoring  the  screens  and  digital  displays  may  have  distorted  the 
information  they  were  receiving....  (Moore,  1988,  pp.  Al) 

For  example,  human  short  term  memory  is  an  intermediate  stage  of 
memory  between  sensory  storage  and  long  term  memory  that  can  last  up  to 
approximately  18  seconds  and  is  limited  to  seven  plus  or  minus  two  items.  Moreover, 
to  increase  the  processing  ability,  people  “chunk”  data;  that  is,  data  is  organized  into 
recognizable  groups.  By  grouping  information  in  this  way,  the  human  processing 
capability  increases  dramatically.  Recognizing  these  strengths  and  limitations,  and 
tailoring  a  system  to  limit  the  processing  weaknesses  and  exploit  the  strengths  should 
be  a  focal  point  of  design  for  a  user  interface. 

fa  Human  Factors  as  a  Force  Multiplier 

If  not  recognized,  human  memory  and  processing  can  become  a  force 
attentuator,  thereby  limiting  capabilities  and  preventing  the  users  from  obtaining  the 


^  Large  Screen  Displays  (LSD’s)  are  42”  x  42”  wall  mounted  displays  used  on  AEGIS 
cruisers  and  destroyers  for  command  and  control. 
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desired  goal.  By  recognizing  these  limitations  and  designing  human-computer 
interfaces  with  them  in  mind,  human  mental  ability  can  become  a  force  multiplier. 

By  emphasizing  the  importance  of  human  factors,  complex  systems  can 
be  designed  to  be  “user  friendly.”  Interface  displays  are  the  keystone  of  command  and 
control  systems  and  the  decision  making  process  on  board  surface  Navy  combatants. 
Correct  design  of  interfaces  will  strengthen  and  assist  the  ability  to  effectively  apply 
assets  in  order  to  achieve  military  objectives. 

B.  PROPOSED  SOLUTION 

This  sub-section  introduces  a  proposal  to  fix  the  deficiencies  that  exist  in 
today’s  command  and  control  systems.  The  Total  Ship  Integrated  Interior 
Communication  and  Control  (IC)2  program  is  a  NAVSEA  initiative  to  solve  the 
problem  of  information  explosion  on  board  U.S.  Navy  ships.  This  system  will  be 
reviewed,  followed  by  a  discussion  of  the  Command  Function — the  display  element  of 
(IC)2.  (IC)2  will  differ  from  existing  command  and  control  systems  by  providing: 

•  seamless  command,  control,  and  communications  because  all  shipboard 
components  will  be  connected  to  a  real-time  fiber-optic  network, 

•  information  available  to  the  Commanding  Officer  and  his  subordinate 
watchstanders  will  provide  the  ability  to  monitor  and  direct  on  board  systems, 
and, 

•  interface  displays  will  consider  the  human  element,  human-computer 
displays  will  be  intuitive  yet  provide  comprehensible  information. 

1.  NAVSEA’s  Integrated  Interior  Communication  and  Control  (IC)2 
System 

NAVSEA  has  designed  and  successfully  demonstrated  the  abilities  of  a  new 
information  transfer  system.  The  next  generation  amphibious  ship — LPD-17 — will 
have  a  complete  fiber  optic  network  system  that  will  connect  all  shipboard  equipment 
and  sensors.  The  Integrated  Interior  Communication  and  Control  (IC)2  System,  will 
integrate  the  entire  ship  as  a  warfighting  unit.  The  flow  of  data  will  be  unrestricted.  By 
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effectively  harnessing  the  data  that  exists  on  this  network,  the  command  and  control 
display  element,  called  the  Command  Function,  will  be  a  critical  element  in  the  overall 
system. 

Implementation  of  (IC)2  will  replace  the  way  current  interior  communication 
collect,  process,  distribute  and  display  orders.  Through  the  use  of  (IC)2,  information 
will  be  available  to  assist  decision  making.  The  challenge  is  to  correctly  and 
methodically  determine  what  to  display  and  how  to  display  it  to  support  the  user. 

a.  Description  of  (IQ2 

(IC)2  is  the  means  by  which  future  ships  will  exercise  command  and 
control.  (IC)2  permits  individual  ship  systems  to  improve  their  connectivity  and 
versatility  by  using  newly  available  technology  to  improve  conventional  interior 
communication  designs.  This  information  management  approach  will  screen,  fuse  and 
integrate  all  shipwide  data  into  real-time  information  to  aid  in  the  command  and 
control  of  the  ship.  (IC)2  will  allow  surface  ship  fighters  to  evolve  from  the  traditional 
use  of  compartmented  information  into  the  integration  of  the  ship  as  a  total  entity. 
LPD-17  will  operate  for  the  first  half  of  the  2 1st  century  % . 

(IC)2  equipment  will  pass  all  data,  information,  voice,  video  and  orders 
between  on  board  users.  The  components  consist  of: 

•  a  shipboard  data  network, 

*  a  video  distribution  system, 

®  a  voice  distribution  system, 

9  the  information  transfer  cable  plant,  and 


The  first  four  components  are  specific  hardware  that  will  facilitate  the  collection, 
processing,  and  transfer  of  data.  They  are  not  addressed  in  this  research.  The 
Command  Function  is  what  users  will  use  to  access  (IC)2,  and  is  discussed  next. 

®  LPD-17  has  an  initial  operational  capability  (IOC)  of  2002. 
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b.  Introduction  to  the  Command  Function 


The  Command  Function  is  the  display  element  of  (IC)2.  The  Command 
Function  will  enable  operators  to  exercise  command  and  control  from  a  workstation 
using  real-time  information  that  traditionally  was  unavailable,  or  at  best,  late.  This 
display  will  provide  fused  summary  data  of  shipboard  functions  to  facilitate  command 
and  control.  This  workstation  which  uses  a  25  inch  color  graphics  monitor  will  enable 
its  to  monitor  systems  and  provide  guidance  to  others. 


C.  THESIS  SCOPE 


This  thesis  provides  prototype  displays  for  the  Command  Function — the 
display  element  of  (IC)2  system.  The  design  recommendations  and  displays  will  be 
forwarded  to  NAVSEA  for  consideration  during  interface  design  and  development. 

The  shortfalls  that  exist  in  current  command  and  control  systems  are  by¬ 
products  of  a  flawed  design  process.  Systems  in  use  today  often  lack  a  crucial  design 
element,  input  and  feedback  from  the  intended-user  to  determine  the  required  system 
functionality.  Systems  are  often  not  designed  around  what  the  user  actually  wants; 
consequently,  the  systems  are  not  “user  friendly.” 

The  term  “user  friendly”  in  engineering  parlance  means  “usable.”  Usability 
relates  to  the  effectiveness  and  efficiency  of  the  interface,  and  to  the  users  reaction  to 
the  interface.  To  ensure  usability  designers  must  accomplish  these  tasks: 

•  Determine  what  the  intended-user  requires  from  a  new  system. 

•  Establish  a  foundation  of  ideas  based  on  the  inputs  of  operational  experts  and 
the  desires  of  intended  users.  Base  the  mock-up  and  initial  prototype  on  these 
requirements. 

•  Document  these  findings  in  such  a  manner  that  system  characteristics  can  be 
outlined  and  so  that  other  designers  can  further  modify  and  build  onto  the 
system. 

The  next  chapter  reviews  the  method  used  to  design  the  Command  Function. 
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II.  METHOD 


This  thesis  develops  functional  specifications,  including  the  required 
functionality  and  associated  system  characteristics,  and  develops  prototype  displays 
for  the  Command  Function  of  LPD-17.  The  method  used  to  design  those  prototypes  is 
discussed  below.  The  process  adopted  closely  follows  a  set  of  contemporary 
commercial  design  guidelines  (Mayhew,  1992)  comprised  of  five  notional  phases. 
These  phases  are: 

(1)  a  definition  of  the  system’s  purpose, 

(2)  the  development  of  the  functional  specifications, 

(3)  the  actual  system  design, 

(4)  system  development,  and 

(5)  test  and  implementation. 

The  present  discussion  addresses  the  second  phase  of  these  design  guidelines, 
the  development  of  the  functional  specifications.  Functional  specifications  are 
determined  by  first  identifying  what  the  system  needs  to  do  from  a  user’s  perspective, 
then  secondly,  isolating  the  system  characteristics  needed  to  meet  those  requirements. 
A  task  analysis  was  used  to  systematically  isolate  and  define  the  performance 
requirements  imposed  on  the  system  by  the  operator.  This  chapter  describes  two  sets 
of  procedures  employed  for  the  task  analysis  of  LPD-17’s  Command  Function. 

The  first  set  concerns  the  five  design  phases  and  their  associated  steps, 
including  a  review  of  NAVSEA’s  work  on  the  (IC)2  program.  It  then  focuses  on  the 
methods  used  to  extend  NAVSEA’s  effort  in  designing  the  interface  for  (IC)2.  The 
second  set  discusses  the  task  analysis  procedure  itself  and  how  it  was  performed. 
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A.  DESIGN  PHASES 


May  hews’  (1992)  approach  to  interface  design  was  selected  because  it  is 
simple,  concise,  and  provides  clear-cut  guidance.  Moreover,  the  approach  is 
commonly  referenced  in  both  commercial  and  military  documents  concerning  human- 
computer  interfaces.  Table  1,  on  the  following  page,  depicts  the  five  phases  which 
comprise  this  approach  a  nd  their  completion  status  with  respect  to  accomplishment  by 
NAVSEA,  and  the  areas  which  will  be  addressed  by  this  research.  The  shaded  portions 
highlights  the  two  specific  areas — the  task  analysis  in  Phase  2,  and  the  mock-up  and 
prototype  in  Phase  3 — presently  addressed.  The  table  shows  that  despite  the 
accomplishments  to  date  on  “Scoping  the  System,”  the  next  phase,  “Developing 
Functional  Specifications,”  must  be  addressed.  The  main  step  in  that  work  is  to 
conduct  a  task  analysis. 


Bo  TASK  ANALYSIS 

The  task  analysis’  approach  adopted  identifies  the  systems’  functional 
requirements  by  observing  and  interviewing  its  intended  end-users.  In  short,  it  solicits 
inputs  from  subject  matter  experts  to  specify  product  requirements.  This  approach 
studies  the  user’s  actions,  work-flow  patterns  and  demands,  and  evaluates  human 
information  processing  limitations,  user  capabilities,  and  task  characteristics.  The 
results  become  the  basis  for  the  conceptual  design  of  a  high-level  mock-up  which,  in 
turn,  is  iteratively  critiqued  by  the  intended-user.  The  task  analysis  therefore,  is  a 
critical  step  in  the  design  process.  If  it  is  incorrectly  done,  the  resultant  system  may 
not  meet  user  expectations  and  operator  performance  could  suffer. 
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The  field  situations  in  which  command  and  control  systems  operate  are 
extremely  complex,  change  very  rapidly,  involve  diverse  operator  job  requirements, 
and  are  typically  characterized  by  extraordinarily  high-levels  of  information  exchange. 
Users’  information  requirements  often  tend  to  be  stated  in  ambiguous,  imprecise,  and 
in  a  context-dependent  manner.  These  user  information  requirements  were 
systematically  identified  by  interviewing  a  sample  of  officers  who  have  had 
command-at-sea  experience.  Contents  from  the  interviews  were  then  subjected  to  a 
content  analysis  which  produce  a  set  of  discrete  information  requirements.  The 
following  introduces  the  sampling  method  used  and  the  task  analysis’  tools  employed 
to  express  the  required  functional  specifications.  These  specifications  were  then  used 
to  develop  the  prototype  displays  for  the  Command  Function.  The  task  analysis  is 
described  first,  followed  by  a  review  of  the  method  used  to  produce  the  mock-up  and 
prototype  displays. 

1.  Sample  of  Subject  Matter  Experts 

Structured  interviews  were  conducted  with  fifteen  senior  officers — members 
of  the  Surface  Warfare  Officers  College  Command,  the  Senior  Officer  Ship  Material 
Readiness  Course,  and  the  Naval  War  College — who  had  command-at-sea  experience 
on  a  broad  range  of  different  ships.  The  communities  that  were  represented  included, 
CRUDES,  Amphib,  Minesweeps,  Combat  Logistic  Force,  and  Carriers.  ^  These  field 
grade  officers,  Commanders  and  Captains,  were  chosen  because  they  were  subject 
matter  experts  with  a  record  of  consistent  proven  performance  at  sea,  and  were 
recognized  as  leaders  in  the  surface  community.  The  interviews  were  designed  to  tap 
what  they  considered  to  be  the  critical  information  requirements  needed  to  meet 
command  and  control  requirements  for  their  respective  ships.  The  interviews  with 
senior  officers  were  followed  by  interviews  with  23  junior  officers,  Lieutenants,  who 
had  experienced  duty  at  sea  and  who  were  prospective  users  of  the  Command 

^  Surface  ships  are  divided  into  groups,  CRUisers  and  DEStroyers  are  called 
CRUDES,  amphibious  capable  ships  are  called  Amphibs;  Combat  Logistic  Force 
ships  are  used  for  supply. 
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Function.  The  goal  of  these  interviews  was  to  determine  what  users  thought  was 
required  from  a  system  designed  to  fully  support  shipboard  command  and  control. 

Extensive  written  comments  were  recorded  during  all  interviews,  and  later 
evaluated  to  discern  patterns  of  responses  which  highlighted  what  these  officers 
thought  they  needed  to  effectively  execute  command  and  control  at  sea.  Moreover,  the 
comments  were  examined  to  reveal  desired  design  features  absent  from  existing 
systems.  The  information  needed  to  exercise  command  and  control  and  the  desired 
new  design  features  were  incorporated  into  the  mock-up  and  prototype  displays. 

2.  Task  Analysis’  Tools 

An  analytic  method  called  Quality  Function  Deployment  (QFD)  was  used  for 
the  task  analysis.  QFD  is  a  methodology  aimed  at  satisfying  the  consumer  by 
translating  their  demands  into  design  goals.  It  is  based  upon  a  simple  premise:  by 
building  a  system  around  the  desires  of  intended-users,  operator  performance 
improves.  QFD,  a  design  method  is  commonly  used  throughout  industry,  is  briefly 
reviewed  below  before  its  application  to  the  present  research  is  described, 
a.  Introduction  to  QFD 

QFD  is  a  way  to  establish  quality  in  a  product’s  design,  manufacturing, 
and  service;  quality  becomes  a  focal  point  in  the  initial  stages  of  design  and  remains 
an  important  design  goal  throughout  the  products  life-cycle.  This  approach  bases 
product  design  on  the  demands  of  the  user.  It  is  a  methodical  plan  for  producing 
quality  by  reviewing  the  product  at  each  stage  of  its  design  and  development.  The 
QFD  method  of  design  was  adopted  for  two  reasons:  it  uses  interviews  and  anecdotal 
narrative  data  which  are  relatively  easy  to  collect;  and  it  produces  detailed 
documentation  as  the  method  is  applied.  This  documentation  ensures  that  user- 
provided  data  is  readily  available  for  the  primary  design  phase  and  subsequent  design 
changes.  The  system’s  final  design  becomes  directly  linked  to  documented  user 
requirements. 
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b.  QFd  Took  Used  In  The  Task  Analysis 

Eight  tools  were  used  in  the  task  analysis:  the  first  four  to  determine 
user  demands,  and  the  second  four  to  determine  the  concomitant  system  requirements. 
Table  2,  on  the  following  page  reviews  the  eight  tools.  This  table  lists  the  goals, 
procedures,  and  the  results  of  the  application  of  each  QFD  tool.  Operator  demands 
were  first  identified  using  the  following  steps: 

•  Intended  users  were  interviewed  to  determine  their  demands. 

0  User  comments  were  translated  into  engineering  design  language. 

®  The  data  was  organized  into  logical  categories. 

°  Specific  characteristics  needed  to  achieve  the  specific  user-demands  were 
identified. 

After  this  data  was  collected  and  organized,  a  conceptual  model — the  first  mock-up 
interface — was  made  for  review. 

The  following  section  discusses  the  manner  in  which  these  design 
characteristics  were  incorporated  first  into  the  mock-up,  and  then  into  the  prototype. 


CUSTOMER  DEMAND  Determine  what  the  •  Interview  the  intended  user  •  A  list  of  demands  that  are  recorded  in 

LUST  users’  want  •  Document  the  users’  demands — in  their  own  words  the  users’  own  words 

•  List  the  demand 

•  Verify  the  list  of  requirements  with  the  intended  user 
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Table  2:  The  Tools  of  QFD:  Goals,  Procedures,  and  Results 


Co  MOCK-UP  AND  PROTOTYPE 


User  requirements  identified  by  the  task  analysis  were  incorporated  in  the 
mock-up  and  prototype.  Data  from  the  task  analysis  and  preliminary  design  decisions 
already  made  by  NAVSEA  were  merged  and  depicted  in  a  paper-and-pencil  mock-up, 
which  was  the  point  of  departure  for  an  iterative  series  of  design  sessions.  This  process 
ultimately  optimize  user-acceptance  by  incorporating  user-defined  functional 
requirements.  Given  the  absence  of  specific  design  guidelines  for  the  initial  interface 
design,  the  process  used  to  translate  user-requirements  into  the  mock-up  was  intuitive. 
It  was  based  on  familiarity  with  the  subject  matter,  familiarity  with  the  criterion 
environment,  and  a  review  of  pertinent  human  factors  and  computer  literature. 

1.  Design  Tools 

The  prototype  displays  were  developed  with  Asymetrix™  object-oriented 
application  Multimedia  Toolbook™.  The  design  was  conducted  using  an  Intel  486 
processor,  Window  NT™  operating  system,  and  a  21”  NEC™  MultiSync  6FGp  high- 
resolution  color  monitor.  The  prototype  screens  were  printed  on  a  Shinko  CHC-S446i 
printer. 


Do  SUMMARY 

May  hews’  (1992)  approach  to  system  design  was  adopted  to  develop  the 
Command  Function.  Quality  Function  Deployment  (QFD),  a  variant  of  task  analysis 
methodology,  was  used  to  identify  user’s  functional  requirements  and  by  extension, 
the  associated  system  characteristics.  Officers  with  command-at-sea  experience  were 
interviewed  and  their  desires  and  opinions  concerning  command  and  control  display 
requirements  were  solicited.  These  narratives  were  analyzed  to  extract  common 
themes  which  formed  the  basis  for  a  mock-up  of  the  Command  Function.  The  next 
chapter  describes  the  results  of  applying  this  methodology. 
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III.  RESULTS 


The  application  of  the  user-centered  design  method  previously  discussed 
yielded  products:  a  set  of  user-defined  system  requirements  and  system  characteristics, 
and  the  interface  display  characteristics  derived  from  those  requirements.  The  first  part 
of  the  present  chapter  discusses  the  results  obtained  from  the  task  analysis.  It  presents 
the  functional  specifications  essential  for  the  Command  Function;  that  is,  the  desired 
functionality  of  the  system  as  stipulated  by  a  representative  sample  of  users,  and  the 
system  characteristics.  The  second  part  reviews  the  actual  interface;  that  is,  prototype 
display  screens.  Two  screens  are  provided  to  exemplify  how  the  user-defined 
requirements  were  incorporated  in  the  design  of  this  interface.  The  remaining  screens 
can  be  reviewed  in  Appendix  B.  The  chapter  concludes  with  a  summary  of  these 
results. 

A.  TASK  ANALYSIS 

The  results  of  the  task  analysis  are  displayed  in  Tables  3  and  4.  These  tables 
depict  summary  data  collected  from  interviews,  and  subsequently  translated  into 
specific  engineering  system  characteristics.  These  data  collectively  comprise  the  basis 
for  the  Command  Function  design  characteristics. 

Table  3,  on  the  next  page,  lists  the  task  requirements  and  resulting  design 
characteristics  the  system  must  meet  from  an  operator’s  perspective  while  performing 
the  job:  that  is,  in  exercising  command  and  control.  Table  4,  on  page  29,  lists  the 
design  requirements  and  associated  system  characteristics  of  the  equipment  designed 
to  support  command  and  control.  Both  tables  reflect  the  data  collected  from  the 
previous  steps  used  in  the  task  analysis. 
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Supporting  Task 


System  Characteristics 


Job  Function 


PROVIDE  C2  TOOLS 

Display  current  tools  available 

0  Display  all  data  from  status  boards 

9  Display  data  in  real-time 
°  Integrate  data  from  phone-talkers 

9  Show  equipment  status,  call  signs, 
and  battle  group  responsibilities 

Use  video 

e  Allow  selection  of  any  video  camera 

Track  organic  units 

®  Track  own  ships  units  display 

-  bearing  /  range,  loadout 

-  limiting  factors,  destination 

Display  surveillance  picture 

•  Integrate  radar  displays 

Show  restrictive  events 

e  Model  current  situation’s  events 

9  Display  limiting  events 

-  show  percent  of  completion 
e  Prevent  errors  during  these  events 

Compare  data 

®  Provide  list  of  available  options 

9  Provide  traditional  checklists 

ASSIST  USER  IN 
PROCESSING  DATA 

Avoid  task  overload 

®  Recognize  memory  capacity 

9  Provide  all  required  data 
•  Use  recognition  instead  of  recall 

0  Use  pictures  /  graphics  instead  of  text 

Assure  fidelity 

°  Display  data  as  it  is  expected 

8  Display  data  realistically 

Ensure  interpretability 

•  Use  pictures  and  graphics 

•  Ensure  logical  representation 

®  Use  familiar  icons  and  layouts 

Rank  information 

9  Prioritize  alarms 

®  Update  displays  based  on  importance 

ASSIST  USER  IN 
MONITORING  AND 
CONTROLLING 
EQUIPMENT 

Show  equipment  status 

8  Display  on  /  off  /  stand-by  status 
®  Use  color  to  amplify  status 

8  Use  pictures  of  equipment 

9  Display  equipment  m  expected 
locations 

®  Display  information  as  it  is  organized 
in  text 

Allow  trend  analysis 

9  Provide  access  to  databases 
°  Correlate  trends 

°  Use  graphs  to  display  information 

Show  configuration  changes 

9  Display  what  changed  and  when 
°  Tell  the  user  why  something  changed 

9  Allow  the  user  to  select  time  limits  of 
query 

Allow  varied  selection  of 
equipment 

9  Allow  queries  of  equipment  by 
-  department,  division,  system,  and 
status 

Table  3:  Job-related  Requirements  and  Associated  System  Characteristics  of  the 

Command  Function 


Design  Function 

Supporting  Task 

System  Characteristics 

ENSURE  RELIABILITY 

Use  both  routine  everyday 
events 

•  Use  inport  and  at  sea 

•  Use  to  conduct  eveiyday  routine  events 
and  real-time  operations 

•  Use  to  train  personnel 

Use  for  emergent  and 
special  events 

•  Use  for  emergencies 

•  Prioritize  information 

Provide  all  the  required 
tools  in  one  place 

•  Display  schedules 

•  Display  training  requirements  and  status 

•  Integrate  video 

•  Access  personnel  records  and  reference 
publications 

Optimize  system 
performance 

•  Minimize  system  crashes 

•  Prevent  errors 

•  Respond  in  adequate  time 

ENSURE  EASE-OF-USE 

Make  system  rapidly 
configurable 

•  Allow  user  to  select  desired  display 
information 

Access  the  infoimation  as  it 
is  expected 

•  Display  elements  logically 

•  Use  pictures  and  graphics  instead  of  text 

•  Do  not  require  extensive  learning 

•  Use  traditional  /  expected  colors 

•  Use  traditional  /  expected  layouts 

Prevent  the  user  from 
getting  lost 

•  Make  the  display  intuitive 

•  Ensure  navigation  pathways  are  logical 

SUSTAIN  COMMAND 
RELATIONSHIPS 

Tailor  the  system  like 
relationships  on  board 

•  Pass  orders  down  only  one  level 

•  Pass  information  up  only  one  level 

•  Screen  certain  data  before  entry  on  the 
network 

Limit  access  based  on  rank 
or  position 

•  Limit  access  to  data  based  on  position 

•  Require  users  to  log  in 

•  Provide  information  security 

USE  IN  PLANNING 

Use  for  C2  planning 

•  Display  outcomes  from  potential 
changes 

Table  4:  Design-related  Requirements  and  Associated  System  Characteristics  of  the 

Command  Function 
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B„  MOCK-UP  AND  PROTOTYPE 

The  mock-up  and  prototype  were  produced  using  the  system  requirements 
defined  in  the  task  analysis.  These  requirements  were  displayed  in  Tables  3  and  4. 
Recall  that  a  paper-and-pencil  design,  a  mock-up,  was  the  basis  for  the  prototype.  The 
discussion  now  focuses  specifically  on  the  prototype  itself.  The  prototype  which 
evolved  as  a  result  of  evaluating  the  mock-up. 

The  prototype  for  the  Command  Function  interface  was  designed  in  two  parts, 
the  background,  and  the  specific  screens.  When  observed  by  the  user,  the  screen  and 
the  background  appear  as  a  single  entity.  Figure  2,  below,  shows  the  layering  effect 
from  an  operators  point-of-view.  By  designing  the  interface  in  two  parts,  screens  with 
specific  information  can  be  layered  on  top  of  permanent  data  elements. 

The  purpose  and  associated  elements  of  both  the  background  and  specific 
screens  are  listed  on  page  32.  First  however,  NAVSEA’s  design  specifications  for  the 
Command  Function  are  reviewed. 

1.  Operator  Interface  Design  Specifications 
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The  basic  operator  interface  design  features  of  the  Command  Function  have 
been  stipulated  by  NAVSEA  (1994).  These  features  include  the  use  of  a  21  inch  or  25 
inch  high-resolution  color  graphics  monitor  with  a  touchscreen — in  place  of  a 
traditional  keyboard — for  operator  interaction.  These  two  features,  along  with  the 
user-defined  functional  requirements,  are  the  basis  for  the  prototype. 

2.  Backgrounds 

The  background  was  designed  to  display  data  required  by  all  subsequent 
screens.  These  data  elements  provide  amplifying  information  to  assist  the  user  in 
evaluating  their  environment.  The  background  is  divided  into  three  parts  to  provide 
distinct  separation  of  information  elements.  This  separation  divides  information 
logically — as  the  user  expects  it — and  reduces  the  possibility  of  operator  sensory 
overload.  The  three  groups  are: 

•  tactical  summary, 

•  status  windows,  and 

•  push  buttons. 

The  specific  location  of  these  elements  on  the  background  can  be  reviewed  on  Figure 
2,  on  the  previous  page.  Although  it  is  desirable  to  allow  the  user  to  configure  the 
display  as  they  see  fit,  these  locations  serve  as  the  default.  The  main  reason  these 
groupings  and  locations  were  selected  is  that  configuration  reflects  how  and  where  the 
user  traditionally  expects  to  find  this  information.  Table  5,  on  page  32,  lists  the  three 
parts  of  the  background  and  describes  their  purpose  and  specific  components. 

There  are  two  backgrounds  used  for  the  Command  Function,  one  used  with  the 
departmental  screens,  and  the  other  with  the  special  evolution  screens.  The  only 
difference  between  the  two  is  the  choice  of  push  buttons:  the  main  background  allows 
navigations  to  the  individual  departments,  the  special  evolution  background  allows 
navigations  to  special  evolution  screens.  Table  6,  on  the  next  page,  lists  the  navigation 
options  of  each  background 
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TACTICAL 

SUMMARY 


Inform  user  of  tactical  situation 


Inform  user  of  ships  parameters 


Navigate  to  other  screens 


8  Condition  of  readiness 

•  Material  condition 

•  EMCON  posture  and  amplification 
°  HERO  posture  and  amplification 

•  Warning  /  Weapon  status 

-  AAW 

-  ASUW 

-  ASW 

e  Flight  deck  status. 

8  Well  deck  status 

8  Ballast  /  de-ballast  status  and  level  at  sill 
8  Time: 

-  local 
-zulu 

•  Ships  course  and  speed 

•  Rudder  angle  indicator 

•  Latitude  and  Longitude  read-out 
8  Selectable  display: 

-  PIM  information 

-  Wind  display,  or 

-  Weather  display 

•  Equipment  on-lme  display: 

-  Engineering  equipment,  or 

-  Combat  System  Equipment. 

8  Restricted  Maneuvering  Label 


•  Equipment 

•  Personnel 

•  New  Messages 
8  Video 

8  Forward 
8  Backward 
8  Administration 
8  Aviation 
8  Combat  Systems 
8  Deck 

8  Embarked  Forces 
8  Engineering 
8  Navigation 
8  Operations 
®  Supply 

°  Special  Evolutions 


Any  department  screen 

Special  Evolutions  Screen  (and  background) 


Any  special  evolution  screen 
Main  Default  Screen  (and  background) 


Table  6:  Navigating  through  the  Command  Function  Screens 
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3.  Screen 


The  individual  screens  display  specific  information  as  the  user  navigates 
through  each  screen.  This  specific  information  is  layered  on  top  of  the  main  or  special 
evolution  background.  The  screens  themselves  are  divided  into  two  groups:  ship 
departments  and  special  evolutions. 

The  purpose  of,  and  the  display  elements  of  the  department  screens  are  listed 
below,  and  on  page  34.  Due  to  the  extraordinary  amount  of  data  present,  the  table  has 
been  divided  into  two  parts,  Table  7a  and  Table  7b.  The  purpose  and  display  elements 
of  the  special  evolution  screens  are  listed  in  Table  8,  on  page  35. 


Screen  Name 

Screen  Purpose 

Display  Elements  On  Screen 

ADMIN 

Provide  typical 
administrative  data. 

•  Gateway  to  SNAP  HI 

•  Provide  at  a  minimum  access 

-  personnel  and  training  records 

-  past  evaluations 

-  instructions,  references  and  reports 

-  ticklers  and  the  plan-of-the-day 

AIR 

Provide  data  about 
embarked  air  element 

•  Tactical  display8  -  default  range  set  at  40  NM 

•  Aircraft  summary  display 

-  A/C#  /  Brg  /  Rng  /  Fuel  /  Serial  #  or  load  / 
destination 

•  Aircraft  flight  plan 

-  integration  of  Air  Tasking  Order  (ATO) 

•  Weather  information  (ceiling,  visibility,  density  / 
pressure  altitude,  wind,  dew  point) 

•  Flight  deck  status 

•  Video  selection  -  flight  deck  or  well  deck 

•  Ships  tactical  communication  plan 

•  Push  button  to  show  boat  schedule 

CS 

Allow  for  monitoring  and 
controlling  of  Combat 
System  equipment 

•  Graphic  display  of  equipment: 

-  on-line,  in  stand-by,  out  of  commission  (OOC) 
a  Text  field  with  above  information. 

•  Ammunition  status 

-  type  and  location,  allowances:  on  board  &  training. 

•  Video  selection 

•  Status  window  of  background  will  automatically  show 
the  Engineering  equipment  display 

DECK 

Provide  status  of  deck 
related  equipment 

•  Tactical  display  -  default  range  set  at  15  NM 

-  emphasis  on  own  ships*  boats 

•  Graphic  display  of  stem  gate  and  well  deck  status 

-  well  deck  depth  /  percent  ballast 

•  Field  with  Sea  state  information,  hangar  door  status, 
life  boat  status,  and  anchor  status 

•  Video  selection  -  well  deck  and  vehicle  stowage. 

Table  7a:  Department  Screens  and  Associated  Display  Elements 


a.  The  tactical  display  is  the  integration  of  the  ships  position,  a  digital  navigation  chart,  and  the  radar 

surveillance  picture.  Range  and  chart  will  be  selectable,  ships  positioning  on  the  display  will  be  moveable. 
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Screen  Name 

Screen  Purpose 

Display  Elements  On  Screen 

EMB 

FORCES 

Provide  embarked  Marine 
commanders  information 
required  for  command  and 
control  of  their  troops 

3  Tactical  Maps  -  integrated  with  tactical  display 

-  allow  overlays  on  land  areas 

-  use  for  planning 
°  Landing  Serial  Table 

-  wave  number  /  serial  /  craft  /  unit  /  beach  /  load 

-  allow  for  amplification  on  demand 

°  Graphic  of  percent  of  MOGAS  on  board 
°  Communication  Field 

-  circuit  status  and  location 

®  Go  /  No  Go  button  to  direct  troop  movement 
•  Push  button  to  display  LFORM 

-  landing  force  operational  reserve  material 

-  ordnance  /  equipment  /  rations  /  fuel 
°  Summary  field 

-  personnel  on  board,  sea  state,  equipment 

ENG 

Allow  for  monitoring  and 
controlling  of  Engineering 
equipment 

®  Graphic  display  of  ship  with  equipment  status: 

-  equipment  on-line,  stand-by,  OOC 
°  Field  with  equipment  information  in  text 

6  Fuel  /  water  /  aviation  fuel  graphs 

6  Push  button  to  navigate  to  Damage  control. 

*  Status  window  of  background  will  automatically  show 
the  Combat  Systems  equipment  display 

NAV 

Provide  information 
normally  collected  at  the 
navigation  table 

®  Tactical  display  -  default  range  set  at  10  NM 
-  provide  specific  navigation  details  on  chart 
°  Call  sign  field 
°  Field  with  fix  information 

*  Status  window  of  background  will  automatically  show 
the  Engineering  equipment  display 

OPS 

Provide  tactical 
information 

•  Tactical  display  -  default  range  set  at  50  NM 
°  Call  sign  field. 

°  Push  button  to  display  battle  group  information: 

-  responsibilities 

-  ships  in  company 

•  Push  button  for  message  retrieval 

-  allow  query  to  database  for  received  msg 

-  access  files  of  stored  msgs 

-  review  new  msgs 

°  Push  button  to  display  schedules 

-  integrate  plan-of-the-day  and  schedule-of-events. 

°  Push  button  to  access  communication  information 

SUPPLY 

Provide  status  of  Supply 
Department 

3  Hotel  service  status 

8  Budgets 

°  Supplies  on  board 
®  Parts  status 

Table  7b:  Department  Screens  And  Associated  Display  Elements  (continued) 
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Screen  Name 


Screen  Purpose 


Display  Elements  On  Screen 


A/C  LAUNCH 

Provide  all  required 
information  for  the  launch 
and  recovery  of  aircraft 

•  Tactical  display  -  default  range  set  at  15  NM 

•  Graphic  display  of  flight  deck,  required  winds  for 
specific  deck  spots 

•  Field  with  launch  /  recovery  cycles 

•  Pitch  and  roll  indicators 

•  Video  of  flight  deck 

•  Status  window  of  background  will  automatically 
show  the  Combat  Systems  equipment  display. 

ANCHORING 

To  anchor 

*  See  Sperry  interface  already  designed 

BOAT  OPS 

Provide  all  required 
information  for  the  launch 
and  recovery  of  boats 

•  Tactical  Display  -  default  range  set  at  15  NM 

•  Sea  State  indicator 

•  Field  with  launch  /  recovery  cycles 

•  Wind  display 

•  Field  with  stem  gate  status 

•  Video  selection 

FIRE /FLOOD 

Damage  Control 

•  See  CAE  Link  Damage  Control  Interface 

MAN  OVER 

BOARD 

Provide  quick  and  easy 
entry  of  position  of  man 
overboard,  and  to  provide 
all  required  information  for 
recovery 

•  Tactical  display  -  default  range  set  at  2NM 

-  ship  will  be  positioned  in  middle  of  screen 

•  Push  button  for  entry  of  position 

-  green  button  for  stba 

-  red  button  for  port 

•  Field  displaying  checklist  for  M.O.B. 

•  Field  with  information  about  OSCAR 

-  brg&mg 

-  time  in  water 

-  water  temp  and  stay  time 

•  Field  with  course  to  steer  to  pick  up  man 

•  Field  displaying  ships’  boat  status 

•  Status  window  of  background  will  automatically 
show  the  Engineering  equipment  display. 

•  Status  window  of  background  will  automatically 
show  the  Wind  display. 

REPORTS 

Display  reports  which  have 
been  labor-intensive 

•  8  o’clock  report  information 

•  12  o’clock  report  information 

SEA  DETAIL 

Provide  all  require 
information  for  safe 
navigation  while  at  sea 
detail. 

•  Navigation  Display  -  like  tactical  display  but  ships 
heading  defaults  to  true  north 

•  Field  with  navigation  courses  /  speed  distance 
remaining 

•  Field  with  communication  circuits 

•  Field  with  anchor  status 

UNREP 

Provide  information 
required  for  planning  and 
conducting  an  underway 
replenishment 

•  Tactical  display  -  to  include  own  ships  position, 
and  unrep  location 

•  Field  with  unrep  ship  data:  CO  /  rig  placement  etc. 

•  Field  displaying  material  for  unrep  /  conrep 

•  Status  bar  and  time-to-go  displays 

SHIP  DEFENSE 

To  quickly  and  effortlessly 
transition  the  ship  into  the 
most  defensive  posture 
available 

•  Tactical  display  -  default  range  set  at  10NM 

-  ships  position  in  middle  of  screen 

•  Push  button  activation  of  ships  defensive  systems 

-  SLQ-32  /  CIWS  /  RAM 

•  Push  button  to  set  General  Quarters 

•  Graphic  summary  of  ships  defensive  systems 

•  Field  with  equipment  on-line 

•  Status  window  of  background  will  automatically 
show  Combat  Systems  equipment  display 

•  Status  window  of  background  will  automatically 
show  graphic  of  wind  display 

Table  8:  Special  Evolution  Screens  And  Associated  Display  Elements 
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4.  Example  Display  Screens 

Two  screens  of  the  Command  Function,  Figures  3  and  4,  are  included  to 
provide  the  user  with  examples  of  how  user-demands  have  been  integrated  with 
human  factors  to  display  what  is  desired — by  the  intended-user — in  a  logical  and  clear 
manner.  The  remaining  screens  are  provided  in  Appendix  B,  on  page  59. 

The  first  screen,  Figure  3  on  the  next  page,  is  the  Main  Default  Screen.  This 
screen  will  be  used  during  normal  operations.  The  screen  is  designed  to  provide  the 
user  with  the  elements  normally  required  to  exercise  “routine”  command  and  control. 
These  elements  are: 

8  a  tactical  display  combining  a  digital  chart,  ships  position,  and  radar 
surveillance 

®  selection  of  ship  specific  check-lists’  to  guide  the  user  through  routine 
operations 

®  a  field  displaying  contact  information.  This  pop-up  field  will  correlate  the 
text  from  the  summary  field  with  the  actual  contact  location  shown  on  the 
tactical  display. 

The  central  focus  of  this  Main  Default  Screen  is  on  safety-of-transit,  navigation  and 
planning.  Operations  which  require  more  in-depth  information  and/or  guidance  can  be 
accessed  at  the  touch  of  a  push  button. 

The  second  screen  used  for  an  example,  Figure  4  on  page  39,  is  the  special 
evolution  screen  Sea  Detail.  This  screen  would  be  selected  by  the  operator  when  the 
ship  is  conducting  or  planning  precise  navigation.  The  information  elements  of  this 
screen  include: 

8  a  tactical  display  with  additional  in-depth  detail  normally  found  on  navigation 
charts 

8  a  pictorial  display  of  the  anchor  status;  the  ready  status  of  each  anchor 

8  a  field  displaying  the  course-to-steer,  required  speed,  distance  remaining  in 
this  navigation  leg,  and  time-to-turn  to  the  next  course.  Additional  course 
information — the  future  courses  and  speeds — is  also  available  at  the  touch  of 
a  button 

®  communications  information,  including  circuits  that  are  on-line 
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Figure  3:  Main  Default  Screen 
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C.  SUMMARY 


The  results  are  a  set  of  design  recommendations  and  the  associated  prototype 
for  the  command  and  control  interface — the  Command  Function — on  LPD-17.  User 
demands  have  been  evaluated  and  basic  functional  requirements  associated  with  a 
surface  ship  command  and  control  systems  have  been  determined.  Using  these  basic 
functional  requirements,  system  characteristics  of  the  Command  Function  were 
determined.  These  characteristics  were  tailored  to  meet  the  user-defined  requirements, 
and  were  the  basis  for  the  mock-up  and  prototype  displays. 
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IV.  DISCUSSION 


The  prototype  display  screens  for  LPD-17’s  Command  Function,  produced  by 
the  method  adopted  in  this  study,  were  presented  and  briefly  discussed  in  the  previous 
chapter.  These  displays  are  the  tangible  products  of  this  design  effort;  but  as  noted  here 
the  selection  and  use  of  the  design  method  itself  departed  from  conventional  practice. 
This  chapter  addresses  the  salient  aspects  of  the  design  method  adopted  herein  and 
uses  the  prototype  display  screens  as  a  basis  from  which  to  discuss  its  general  concepts 
and  principles.  The  first  section  places  the  prototype  screens  in  context;  that  is,  they 
really  reflect  only  a  first  generation  design  effort.  The  second  section  contrasts  the 
current  method  with  others  commonly  used  today. 

A.  PROTOTYPE  DISPLAY  SCREENS 

The  two  screens  presented  in  the  previous  chapter  reflect  a  careful  accounting 
of  user-demands  and  an  incorporation  of  accepted  design  principles.  These  screens, 
however,  are  first  generation  displays  and  their  design  will  require  additional  iterations 
during  the  remaining  design  phase  itself,  and  later,  during  developmental  and 
operational  test  and  evaluation  of  the  integrated  system.  The  displays  were  designed 
based  on  inputs  of  the  intended-users  and  shaped  by  technical  literature  from  the  fields 
of  computer  science  and  human  factors.  Again,  these  products  reflect  activity  at  the 
very  beginning  of  the  design  phase.  By  presenting  this  first  generation  prototype  to  the 
intended-operator  at  this  early  design  stage,  the  interface  will  be  subjected  to 
modifications  based  both  on  user-requirements  and  relevant  technical  literature. 
Accordingly,  time  is  not  wasted  at  a  later  and  more  costly,  stage  of  development.  This 
rudimentary  interface  is  simply  a  point-of-departure  for  subsequent  design 
enhancements. 
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The  screens  themselves  reflect  straight-forward  design  objectives.  The 
arrangements  of  informational  elements  were  designed  to  enable  operators  to  access 
the  information  they  need  to  efficiently  and  effectively  exercise  command  and  control 
on  LPD-17.  This  stage  of  design  took  an  iterative  approach.  Operational  experts 
repeatedly  evaluated  the  design  to  ensure  the  interfaces  provided  what  they  wanted, 
and  displayed  this  information  in  a  manner  they  clearly  understood. 


The  interface  between  the  operator  and  shipboard  command  and  control 
systems  is  frequently  cited  as  the  weak  link  in  the  overall  design  of  the  integrated 
systems.  To  date,  no  particular  school  of  design  guidance  has  been  accepted  in  either 
the  rapidly  advancing  commercial  sector,  or  the  slow  and  methodical  acquisition 
procedures  of  the  Department  of  Defense.  Computer  system  interfaces  need  to  be 
designed  around  user-requirements  to  ensure  acceptance,  they  must  be  “usable.” 

Selecting  an  interface  design  method  must  ultimately  produce  a  “usable” 
system.  User-centered  methods  provide  the  required  iteratations  during  design  and 
development  to  collect,  represent,  and  analyze  data  obtained  from  the  intended  users. 
This  process  increases  the  likelihood  that  the  resulting  interface  will  display  what  the 
intended  user  actually  wants,  and  consequently  operator  performance  should  improve 
as  users  come  to  rely  on  the  system. 

The  design  methods  employed  to  produce  today’s  computer  interfaces  for  the 
surface  Navy  often  do  little  to  ensure  cognitive  compatibility,  which  is  the  extent  that 
an  interface  accomplishes  a  task  in  the  manner  the  user  expects  to  accomplish  that 
task.  The  resulting  interfaces  are,  in  general,  not  considered  “user  friendly”.  In  fact, 
end-users  often  wonder  whether  designers  solicited  opinions  from  fleet  users  during 
the  design  or  if  the  interface  was  designed  in  a  “box;”  that  is,  in  isolation.  To  provide  a 
basis  for  comparison,  the  common  method  used  today  in  interface  design  is  contrasted 
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with  the  method  used  in  the  present  research — a  method  committed  to  user-centered 
design. 

1.  Methods  Used  Today 

Approaches  employed  to  design  interfaces  today  typically  do  not  use 
procedures  needed  by  designers  to  ensure  that  the  systems’  broad  design  objectives 
meet  a  fleet  operator’s  requirements.  There  is  insufficient  design  guidance  and  few 
design  tools  available  to  interface  developers  for  them  to  consistently  make  fleet¬ 
relevant  decisions  during  the  design  process.  In  military  procurement  programs,  which 
are  typically  constrained  by  inflexible  schedules  and  an  intolerance  to  cost  over-runs, 
designers  tend  to  make  decisions  from  a  narrow  technical  engineering  perspective 
which  may  not  reflect  a  boarder  operational  fleet  perspective.  Many  interfaces  used  in 
the  surface  Navy  reflect  this  narrow  engineering  design  perspective. 

The  practice  of  relying  on  a  contractor — typically  cost  and  time  constrained 
and  removed  from  the  fleet — to  determine  both  system  functionality  and  subsequently 
system  design,  is  common.  This  practice  of  simultaneously  relying  on  contractors, 
while  not  ensuring  they  solicit  current  fleet  input,  has  an  accepted  practice  in  the  face 
of  increasingly  complex  systems,  and  increasingly  complex  informational 
requirements,  both  of  which  in  turn  are  imposed  by  increasingly  complex  mission 
requirements.  It  is  the  operator,  and  by  extension  the  mission,  that  is  adversely 
impacted.  Fleet  personnel  will  readily  adapt  to  design  short-falls,  but  often,  it  is  at  the 
expense  of  mission  capabilities.  Generally  operators  are  unaware  of  design 
alternatives,  they  use  the  tools  that  are  available  “....they  generally  accept  the  result 
because  when  you  give  them  an  application,  the  way  it  looks  is  the  way  it  is.”  (Nielsen, 
1994,  pp.  378)  Clearly,  it  is  incumbent  on  the  designers  to  provide  the  fleet  with 
carefully  considered  designs  which  are  fleet  validated. 
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Relying  on  the  commercial  sector  as  the  dominant  source  of  design 
input  is  a  poor  way  to  determine  system  requirements.  Although  the  commercial 
sector,  or  more  specifically  contractors,  is  often  staffed  with  retired  or  ex-military 
personnel,  these  same  people  may  not  reflect  today’s  fleet  operators.  More  specifically, 
the  methods  currently  used  by  contractors  are  often  personnel  dependent.  Employees’ 
memories,  the  breadth  of  their  individual  experiences,  and  the  extent  to  which  they  can 
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solutions  to  contemporary  problems  are  based  (Nielsen,  1994).  This  method  of  design 
limits  the  range  of  possible  solutions.  Moreover,  an  experience  dependent  approach 
may  possibly  perpetuate  design  errors  unrecognized  in  predecessor  systems. 

Given  the  rapidity  with  which  technology  is  advancing,  design  ideas, 
and  both  developmental  and  operational  test  and  evaluation,  must  be  based  on  today’s 
fleet.  An  iterative  approach  must  he  used  to  solicit  inputs  from  both  master-level 
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intended-users  of  the  new  system.  For  the  Command  Function,  the  master  is  typically  a 
Captain  or  Commander  with  command  experience,  and  the  journeyman  is  today’s 
Lieutenant. 
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2.  User-Centered  Design 

The  design  process  reflected  in  this  research  is  a  method  based  on  user- 
centered  design.  It  is  not  essential  that  one  particular  method  is  chosen  over  another,  as 
long  the  method  that  is  chosen  focuses  on  the  user  and  accommodates  their 
preferences  and  requirements.  In  this  regard,  the  present  effort  used  Mayhew’s  (1992) 
guidance,  and  by  following  its  prescribed  steps  used  the  associated  guidelines  for  an 
iterative  approach  to  design. 

The  focal  point  of  user-centered  design  is  obviously  the  user.  For  this  approach 
to  be  successful,  designers  must  understand  the  user.  If  they  understand  both 
demographic  characteristics  and  fundamental  job  requirements,  they  then  are 
positioned  to  actively  solicit  meaningful  input  for  design.  Fleet  input,  including  initial 
ideas  and  subsequent  evaluation,  becomes  the  predominant  criterion  on  which  design 
decisions  are  based.  User-determined  requirements  are  solicited  from  both  subject 
matter  experts  and  the  intended-operators.  These  anecdotal  accounts  of  operators’ 
desires  are  then  balanced  with  basic  design  principles.  Transforming  the  users’  desires 
into  system  characteristics,  and  balancing  these  ideas  with  established  design 
principles  ensures  usability.  Models  are  used  to  represent  system  functionality  and  are 
iteratively  evaluated  by  the  user  to  assure  fleet  relevance.  Two  procedural  elements  of 
design,  the  sample  of  users  which  affect  the  design  process,  and  the  set  of  design 
principles  used  to  produce  the  initial  prototype  are  critical  to  the  overall  process. 
a.  Sample  of  Users 

An  important  design  element  is  gathering  and  interpreting  fleet  input. 
In  the  present  case,  inputs  from  subject  matter  experts  located  at  the  Naval  Education 
and  Training  Center  at  Newport,  Rhode  Island  were  solicited.  The  Command  Function 
itself  is  a  tool  used  to  support  the  command  and  control  process.  Naval  organizations 
in  Newport  presented  a  broad  range  of  diverse  experience  on  command  and  control. 
As  previously  reported,  extensive  interviews  were  conducted  with  members  of  the 
Surface  Warfare  Officers  College  Command  Staff,  the  Senior  Officer  Ship  Material 
Readiness  Course,  and  the  Naval  War  College.  Junior  Officers,  the  eventual  intended- 
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users  of  the  Command  Function,  were  found  throughout  the  waterfront  and  on  afloat 
units.  Another  excellent  and  concentrated  source  of  junior  officers  was  found  at  the 
Naval  Postgraduate  School  (NFS)  in  Monterey.  This  School  provided  readily 
accessible  volunteers  with  diverse  backgrounds.  Subject  matter  experts  from  these 
sources  provided  inputs  to  the  design  which  reflect  not  only  diverse  technical 
backgrounds,  but  inter-generational  aspects  as  well. 

b.  Basic  Design  Principles 

The  basic  principles  used  for  the  design  of  the  Command  Function 
interface  are  listed  in  Table  9,  on  page  50.  These  principles  are  a  summary  of  ideas 
collected  from  the  technical  engineering  literature  encompassing  interface  design  and 
from  the  common  desires  of  fleet  personnel. 

c.  Future  Research 

LPD-17’s  Command  Function  interface  is  by  no  means  complete.  The 
prototype  displays  produced  by  this  research  are  an  initial  step  in  the  design  phase. 
Further  design  is  needed  before  the  development  phase  begins  and  NPS  can  provide 
this  work.  NPS  can  provide  subject  matter  experts  with  recent  fleet  experience  and  the 
technical  design  expertise  needed  to  integrate  this  fleet  experience  with  engineering 
principles  to  achieve  the  desired  user-centered  results.  Student  officers  at  NPS  have  a 
selfish  interest  to  ensure  that  quality  products  are  provided  to  the  fleet,  as  they  will 
soon  return  to  sea.  The  six  recommendations  which  follow  provide  additional  avenues 
for  further  research  at  NPS. 

9  Examine  the  information!  elements  displayed  on  each  screen.  Continue  to 
solicit  fleet  input  to  determine  missing  elements  and  to  critique  current 
displays.  Verify  that  the  colors,  shapes,  and  layouts  used  to  simulate  the 
traditional  environment  are  accurate.  Modify  and  update  the  displays  during 
this  iterative  process. 

®  Evaluated  the  prototype  display  in  a  realistic  shipboard  environment. 
Allow  intended-users  to  “play”  with  the  prototype  display  in  a  shipboard 
environment.  Real-time  data  is  not  required,  operators  will  be  evaluating  the 
display  screens. 
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•  Conduct  additional  analysis  of  the  data  collected  during  the  functional 
specifications.  Review  the  data  collected  and  weigh  the  user-determined 
functionality  against  the  system  characteristics.  Use  a  method  like  QFD  to 
determine  the  importance  of  each  user-demand.  Compare  the  results  of  the 
analysis  with  the  prototype  displays. 

•  Review  the  system  display  characteristics  to  determine  which  items  a 
user  might  need  to  tailor.  Review  the  situations  this  interface  will  be  used 
in,  and  identify  the  particular  elements  an  operator  might  need  to  change. 

•  Conduct  Laboratory  Experiments.  Determine  optimum  displays  to  provide 
rapid  recognition  and  maximum  information  transfer.  Review  how  the  use  of 
color,  shapes  and  information  layout  affects  the  users’  perception  of  the 
displayed  information. 

•  Determine  required  element  refresh  rate.  Determine  the  minimum  graphic 
refresh  rate  for  each  specific  display  element. 
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Way  to  accomplish 


ENSURE  DESIGN  IS 


“Make  the  job  easier  and 
better  for  the  user,  as 
determined  by  the  user.” 


RECOGNIZE  HUMAN 
INFORMATION 


“Display  information 
not  data.” 


MATCH  THE  SYSTEM 
WITH  REAL-WORLD 


PROVIDE 

CONSISTENCY  AND 
ADHERE  TO 


“Speak  the  users' 
language.” 


INSTEAD  OF  RECALL 


AND  MINIMALIST 
DESIGN 


ENSURE  VISIBILITY 
OF  SYSTEM  STATUS 


“Make  information 
visible  or  easily 
retrievable.” 


“Keep  user  informed  of 
what  is  going  on.” 


°  Know  the  user 
°  Involve  subject  matter  experts, 
intended-users,  and  human 
factors  experts  during  design 
•  Define  requirements  in  the  fleet 
°  Provide  a  system  model  for 
critique 


•  Do  not  overload  the  user 
°  Use  cognitive  directness 

•  Draw  on  real  world  analogies 
«  Organize  displays  to  manage 

complexity 

°  Use  pictures  instead  of  text 
o  Display  information  the  way  the 
user  expects  it 


» Access  information  logically 
o  Do  not  require  the  user  to  learn 
new  methods  /  tools 


•  Be  consistent 

3  Keep  displays  simple 

•  Use  traditional  colors  /  icons  / 
shapes  /  coding 

•  Show  the  user  what  they  expect 


®  Do  not  require  the  user  to 
remember  information 
displayed  elsewhere 
8  Provide  all  the  tools  required  to 
perform  a  task 


8  Contain  only  the  information 
that  is  needed  for  that  task. 


feed  bac 


C.  CHAPTER  SUMMARY 


A  system  design  which  focuses  on  the  demands  and  desires  of  the  intended- 
user  is  more  likely  to  succeed  than  one  which  bases  design  decisions  on  limited 
technical  and  engineering  inputs.  By  isolating  and  accommodating  the  user’s  desires 
the  interface  will  ultimately  reflect  what  users  want;  therefore  the  likelihood  that  the 
interface  will  be  both  usable  and  relied  on  will  increase.  User-interfaces  employed  on 
board  surface  ships  must  reflect  the  desires  and  demands  of  the  fleet.  User  input  during 
the  initial  design  and  subsequent  development  is  the  key  to  both  fleet  acceptance  and 
the  production  of  a  quality  interface. 
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V.  SUMMARY  AND  CONCLUSION 


The  environment  in  which  command  and  control  decisions  are  made  on  board 
Navy  ships  is  extremely  complex.  The  advent  of  automated  computer  processing  has 
increased  the  amount  of  data  available  to  the  operator,  but  this  increase  in  volume  has 
not  reduced  the  associated  workload  on  the  operator.  Changing  mission  requirements 

! 

and  technological  advances  have  imposed  additional  responsibilities  on  the 
commander.  Computer  systems  can  be  used  to  effectively  harness  the  voluminous 
amounts  of  data  and  assist  the  operator  in  exercising  command  and  control.  The 
keystone  to  ship  board  command  and  control  systems  is  the  interface — the 
electronically  mediated  workspace  used  by  the  operator  to  access  the  underlying  data. 

To  effectively  design  and  build  a  user  interface  designers  must  understand  both 
the  required  elements  of  ship  board  command  and  control,  and  also  the  way  these 
elements  are  used  during  the  command  and  control  process.  Following  systematic 
design  procedures,  these  mission  essential  elements  are  captured  and  translated  into 
system  characteristics.  This  research  followed  a  set  of  systematic  design  procedures 
and  produced  a  prototype  interface  for  command  and  control  on  board  LPD-17.  This 
prototype  is  the  beginning  of  the  design  phase.  It  is  a  design  based  on  two  simple 
straight-forward  considerations:  provide  what  the  user  wants,  and  tailor  those  wants 
with  acceptable  design  principles. 
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APPENDIX  A.  THE  VINCENNES  INCIDENT 


The  following  condensed  details  of  the  downing  of  Iran  Air  flight  655  by  USS 
VINCENNES  are  taken  directly  from  the  official  investigation.  (Fogarty,  1988.): 

Summary: 

On  3  July  1988,  the  USS  VINCENNES  (CG  49),  operating  in  the 
Southern  Persian  Gulf  as  a  unit  assigned  to  Commander,  Joint  Task 
Force  Middle  East,  downed  a  civilian  airliner,  Iran  Air  flight  655  on  a 
routine  scheduled  flight  from  Bandar  Abbas  to  Dubai,  with  two  SM-2 
missiles 

Background  scenario: 

In  the  three  day  period  prior  to  the  incident,  there  was  heightened 
air  and  naval  activity  in  the  Persian  Gulf  Iraq  conducted  airstrikes 
against  Iranian  oil  facilities  and  shipping  30  June  through  2  July  1988. 
Iranian  response  was  to  step  up  ship  attacks.  Additionally,  Iran 
deployed  F-14 ’s  from  Bushehr  to  Bandar  Abbas.  U.S.  Forces  in  the 
Persian  Gulf  were  alerted  to  the  probability  of  significant  Iranian 
military  activity  resulting  from  Iranian  retaliation  for  recent  Iraqis 
military  successes.  That  period  covered  the  fourth  of  July  weekend 

During  the  afternoon  and  evening  hours  of  2  July  1988  and 
continuing  into  the  morning  of  3  July  1988,  Iranian  Revolutionary 
Guard  Corps  (IRGC)  armed  small  boats  (Boghammers,  and  Boston 
Whalers)  positioned  themselves  at  the  western  approach  to  the  Straits 
of  Hormuz  (SOH).  From  this  position,  they  were  challenging  merchant 
vessels,  which  has  been  a  precursor  to  merchant  ship  attacks.  On  July 
2  1988,  USS  ELMER  MONTGOMERY 1 1  was  located  sufficiently  close 
to  a  ship  attack  in  progress  as  to  respond  to  a  request  for  distress 
assistance  and  to  fire  warning  shots  to  ward  off  IRGC  small  boats 
attacking  a  merchant  vessel. 

3  July  Surface  Engagement: 

On  the  morning  of  3  July  1988,  USS  ELMER  MONTGOMERY  was 
on  patrol  in  the  northern  portion  of  the  Straits  of  Hormuz.  At 
approximately  0330Z,  USS  MONTGOMERY  observed  seven  small 


A  Standard  missile  (SM-2)  is  a  medium  range  missile  designed  for  surface-to-air 
engagements. 

11  USS  ELMER  MONTGOMERY  is  an  Oliver  Hazard  Perry  Class  Frigate,  designed 
for  anti-submarine  and  anti-air  warfare. 


Iranian  gunboats  approaching  a  Pakistani  merchant  vessel.  The  small 
boats  were  reported  by  USS  MONTGOMERY  to  have  manned  machine 
gun  mounts  and  rocket  launchers. 

Shortly  thereafter,  USS  MONTGOMERY  observed  a  total  of  13 
Iranian  gun  boats  breaking  into  three  groups.  Each  group  contained  3 
to  4  gun  boats  with  one  group  of  four  boats  taking  position  off  USS 
MONTGOMERY’S  port  quarter.  At  04UZ,  USS  MONTGOMERY 
heard  the  gun  boats  over  bridge  to  bridge  challenging  merchant  ships 
in  the  area.  USS  MONTGOMERY  then  heard  5  to  7  explosions  coming 
from  the  north.  At  0412Z.  “Golf  Sierra” 12  directed  USS  VINCENNES 
to  proceed  north  to  the  vicinity  of  USS  MONTGOMERY  and  investigate 
USS  MONTGOMERY ’s  report  of  small  boats  preparing  to  attack  a 
merchant  ship.  USS  VINCENNES’S  helo  (OCEAN LORD  25  /Lamps 
Mk  III  helo)  on  routine  morning  patrol,  was  vectored  north  to  observe 
the  Iranian  small  boat  activity.  USS  VINCENNES  was  also  monitoring 
a  routine  maritime  patrol  of  an  Iranian  P-3  operating  to  the  west.  At 
approximately  0615Z,  the  USS  VINCENNES’S  helicopter  was  fired 
upon  by  one  of  the  small  boats.  USS  VINCENNES  then  took  tactical 
command  of  USS  MONTGOMERY  and  both  ships  proceeded  to  close 
the  position  of  the  helicopter  and  the  small  boats  at  high  speed  As  USS 
VINCENNES  and  USS  MONTGOMERY  approached  the  position  of  the 
small  boats,  two  of  them  were  observed  to  turn  towards  USS 
VINCENNES  and  USS  MONTGOMERY.  The  closing  action  was 
interpreted  as  a  demonstration  of  hostile  intent.  USS  VINCENNES 
then  requested  and  was  given  permission  by  CJTFME  to  engage  the 
small  boats  with  gunfire.  At  approximately  0643Z,  USS  VINCENNES 
opened  fire  and  was  actively  involved  in  the  surface  engagement  from 
the  time  Iran  Air  flight  655  took  off  from  Bandar  Abbas  through  the 
downing  of  Iran  Air  flight  655. 

During  the  course  of  the  gun  engagement  of  the  Iranian  small  boats, 
the  USS  VINCENNES,  at  approximately  0654Z,  had  maneuvered  into  a 
position  one  mile  west  of  the  centerline  of  civilian  airway  Amber  59. 
The  USS  SIDES  ^ ,  transiting  from  east  to  west  through  the  SOH,  was 
approximately  18  miles  to  the  east  and  became  involved  in  the  evolving 
tactical  situation. 


^  Golf  Sierra  is  the  call  sign  of  the  Anti-Surface  Warfare  Commander. 

^  USS  SIDES,  another  Oliver  Hazard  Perry  Class  Frigate,  was  also  assigned  to  the 
Persian  Gulf. 
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Bandar  Abbas  /  Iran  Air  flight  655 /air  engagement: 

On  3  July  1988,  at  approximately  0647Z,  an  Iran  Air  Airbus  300, 
Iran  Air  flight  655,  took  off  from  the  Bandar  Abbas  joint  military  / 
civilian  airport  destined  for  Dubai  airport.  The  flight  was  a  routine 
scheduled,  international flight  via  commercial  airway  Amber  59.  ^ 

Vincennes  —  Critical  Decision  Window: 

At  approximately  0647Z  -  Iran  Air  flight  655  was  detected  by  the 
USS  VlNCENNE’s  AN/SPY- 1 A  radar  bearing  025  degrees,  47  NM  ^ , 
and  was  assigned  TN  4131  ^ .  The  aircraft  continued  to  close  USS 
VINCENNES  with  a  constant  bearing,  decreasing  range.  At 
approximately  0649Z,  USS  VINCENNES  issued  warnings  on  Military 
Air  Distress  (MAD)  (243.00  Mhz)  and  at  0650Z  began  warnings  on 
International  Air  Distress  (IAD)  (121.5 Mhz)  to  TN  4131  located  025 
degrees,  40NMfrom  USS  VINCENNES. 

At  approximately  0650Z  -  several  USS  VINCENNES  CIC  personnel 
heard,  on  internal  Combat  Information  Center  (CIC)  voice  circuits,  a 
report  of  F-14  activity.  A  momentary  Mode  11-1100  IFF 17  indication 
was  detected  which  was  correlated  with  an  Iranian  F-14.  This  was 
reported  throughout  CIC  over  internal  CIC  voice  circuits.  Continuous 
MAD  and  IAD  warnings  were  ordered  at  30NM  (5  total  warnings  on 
MAD  and  4  total  warnings  on  IAD).  USS  VINCENNES  continued  the 
surface  engagement  and  experience  a  foul  bore  in  Mount  51  18 .  In 
order  to  unmask  the  after  gun  mount,  full  rudder  (at  30  knots)  was 
applied  This  added  to  the  increasing  tension  in  CIC. 


^  Commercial  air  ways  are  20  miles  wide,  the  latitude  and  longitude  of  the  center  of 
the  airlane  are  published  and  readily  available. 

^  A  nautical  mile  (NM)  is  a  unit  of  measurement  at  sea,  based  on  the  length  of  a 
minute  or  arc  of  a  great  circle  of  the  earth — equal  to  2000  yards. 

^  Track  number  (TN)  is  how  the  Navy  Tactical  Data  System  (NTDS)  distinguishes 
between  different  contacts.  Each  contact  is  assigned  its  own  track  number,  commonly 
referred  to  as  “track  four  one  three  one”. 

1 7 

Identification  Friend  or  Foe  (IFF)  is  an  electronic  challenge  and  reply  system  that 
uniquely  identifies  aircraft.  This  system  is  required  on  all  aircraft. 

^  Mount  51  is  the  forward  5  inch  gunmount  located  on  the  forecastle;  the  after 
gunmount.  Mount  52,  is  located  near  the  stern. 
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At  approximately  0651Z  -  as  TN  4131  closed  to  28  NM,  USS 
VINCENNES  informed  CJTFME  that  she  had  a  closing  Iranian  F-14, 
which  she  intended  to  engage  at  20NM  unless  it  turned  away.  USS 
VINCENNES  requested  concurrence.  CJTFME  concurred  but  told  USS 
VINCENNES  to  warn  the  aircraft  before  firing.  Warnings  continued, 
but  no  response  from  TN  4131  was  received,  nor  did  it  turn  away. 

At  approximately  0652Z  -  warnings  continued  over  both  IAD  and 
MAD.  Still  no  response.  Although  TN  4131  reached  the  20  NM  point, 
the  CO  decided  not  to  engage.  The  order  was  given  to  illuminate  the 
contact  with  fire  control  radar.  There  were  no  ESM19  indications.  TN 
4131  was  ascending  through  10,000 feet. 

At  approximately  065 3 Z,  at  15-16  NM,  the  last  warning  over  IAD 
was  given  by  USS  SIDES  to  the  aircraft  bearing  204  degrees  to  USS 
VINCENNES,  range  15.5  NM.  During  the  last  30  seconds  of  this 
minute,  the  CO  made  his  decision  to  engage  TN  4131. 

At  approximately  0654Z,  the  CO  turned  the  firing  key.  Two  SM-2 
Blk  II  missiles  left  the  rails.  They  intercepted  Iran  Air  flight  655  at  a 
range  of  8  NMfrom  USS  VINCENNES  at  an  altitude  of 13,500 feet. 

(Fogarty,  1988.  pp.  4-6.) 


Electronic  Surveillance  Measures  (ESM)  is  used  to  detect  electronic  emissions,  it  is 
used  to  assist  in  identification.  Its  function  is  similar  to  a  high-tech  radar  detector, 
commonly  used  in  cars. 
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APPENDIX  B.  SCREENS  OF  THE  COMMAND  FUNCTION 

This  Appendix  displays  the  supplemental  interface  screens  of  the  Command 
Function.  The  prototype  displays  included  in  this  appendix  are: 

•  Aviation  Department 

•  Combat  Systems 

•  Deck  Department 

•  Embarked  Forces 

•  Engineering  Department 

•  Navigation 

« Operations  Department 

•  Supply  Department 

•  Special  Evolutions  Default 

•  Aircraft  Launch 

•  Small  Boat  Operations 

•  Man  over  board 

•  Special  Report 

•  Underway  Replenishment 

•  Ship  Defense 

Each  screen  is  a  collection  of  information  display  elements.  The  display 
elements  of  each  screen  are  listed  in  Tables  7  and  8,  on  pages  33  and  35  respectively. 
Certain  screens  are  not  included  in  this  section.  The  Main  Default  Screen,  and  the  Sea 
Detail  Screen  are  on  page  37  and  39.  Displays  for  anchoring,  and  damage  control — 
fire  and  flooding — have  already  been  designed  and  developed  NAVSEA  sponsored 
contractors.  These  displays  should  be  iteratively  reviewed  to  ensure  they  provide  the 
basic  user-defined  requirements,  and  that  they  adhere  to  sound  design  principles.  A 
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weapon  firing  display  is  also  not  included.  This  interface  in-and-of-itself  is  worthy  of 
extensive  research  and  should  be  addressed  separately. 

These  displays  are  prototypes,  and  accordingly  they  represent  a  proposed  draft 
of  the  Command  Function  characteristics.  To  ensure  a  successful  design  of  the  of  the 
Command  Function  interface,  these  displays  must  be  continually  critiqued  and 
modified  with  the  intended  user  in  mind.  The  prototype  screens  that  follow  are 
reproductions  from  an  interface  development  tool,  Asymetrix™  Multimedia 
Toolbook™;  they  were  designed  to  be  displayed  on  a  21  or  25  inch  high-resolution 
color  graphics  monitor. 
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igure  6:  Combat  Systems  Screen 


Figure  8:  Embarked  Forces  Screen 
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Figure  9:  Engineering  Department  Screen 
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;  11:  Operations  Department  Screen 
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79 


Figure  14:  Aircraft  Launch  Screen 


Figure  15:  Small  Boat  Operations  Screen 


Figure  17:  Special  Reports  Screen 


gure  18:  Underway  Replenishment 
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